【レポート】AWS Summit Tokyo 2017: セイコーエプソンのデータプラットフォームビジネスにおけるサーバレスアーキテクチャへのマイグレーション #AWSSummit

5/30〜6/2の日程で開催されたAWS Summit Tokyo 2017、
当エントリでは6月1日に行われた導入事例トラック 2、 「セイコーエプソンのデータプラットフォームビジネスにおけるサーバレスアーキテクチャへのマイグレーション」 についてレポートします。

セッション概要

当セッションの登壇者及び概要は下記の通りです。
http://www.awssummit.tokyo/summit/index.html#D3T5-5

セッションレポート

西澤氏、李氏の両名による、海外で展開しているプリンティングソリューションをAWSへマイグレーションした際の事例紹介。

現状の問題点から、前段階の「データセンター・マイグレーション」までを西澤氏、「システム・マイグレーション」については当プロジェクトを主導した李氏によってプレゼンテーションが行われました。

今回、疎結合だった元システムからサーバレス・アーキテクチャへのシステムマイグレーションは実質6ヶ月ほどで完了したとのことです。

会社概要＆サービス概要

以下、西澤氏より：

• 事業概要
  • プリンティングソリューションズ
  • ビジュアルコミュニケーション
  • ウェアラブル産業プロダクツ
• プリンティングソリューションズのレシートプリンタ
  • 海外が中心
  • 多種多様なプリンターのラインナップ
• レシートデータプラットフォーム概要
  • OmniLink Merchant Services
  • 北米でのサービス
  • レシート印刷データをそのままAWSに蓄積、二次利用できるように解析
    • レシートデータの解析、店舗、日時、品目、単価、合計、税金など

データセンター・マイグレーション

• 昨年(2016年)：データセンターマイグレーション
  • DCを自己専有型からサービス利用型へ
  • オンプレミスからの移行にあたりシステムを構築した
• システム運用(当時)
  • IT部門（基盤、セキュリティ）　がAWSリソース（コンピューティング、インスタンス、RDS）を管理
  • ビジネス側がIT部門に申請し供給されていた
  • 供給されるリソース(EC2、RDS)が3階層モデル（オンプレミス時代のモデル）が前提になっていた
  • ビジネス側もオンプレミス思考のまま構築していた
  • 当初計画ではスケーラビリティの優先度は低かったが、新機能追加がしづらい構成で、デプロイミスも発生していた
  • そのうちスケールも必要になってきた
  • 次のステップとしてサーバレスに
• 課題：全てのビジネスロジックがアプリケーションサーバ上で動いている
  • スケールアウト時に非効率になっていた
  • システムリソース枯渇
  • 同期処理でブロック状態

システム・マイグレーション

ここから李氏に交代：

• 解決に向けた設計プリンシプル（原則、主義）
  • スケーラビリティ
  • スケールアウトに向いた設計
  • 疎結合
  • マネージドサービスの活用
  • コアビジネスにリソースを投入しなくてはならない、AWSに任せられるところは任せる
• Webソケット経由
• 解析エンジンの部分がキモなのでここをスケール出来るように
• ビジネスロジック
  • 「ためる」→「解析する」→「提供する」
  • 設計メンバー全員がこのロジックを共有しないと分からなくなる

「ためる」

• Webソケットで接続しデータを吸い上げる
• レシートプリンタ > EC2 > Kinesis Stream > Lambda > S3
  • Kinesis Firehoseはバッファ間隔がリアルタイムでない（のでStreamを採用した）

「解析する」

• S3 > SQS > ElasticBeanstalk(EB) Worker(解析) > Kinesis Streams > Lambda
  • WorkerはSQSと相性がよいのでオススメ
  • 解析結果をKinesisに格納
  • 疎結合を継続するため

「提供する」

• S3 or Aurora > EB > Lambda > API Gateway
  • API Gatewayから顧客に提供する

運用上の改善効果

• 当初
  • デプロイ -> マニュアル、スクリプト、属人化
  • 監視 -> 内製モニタリングシステム
• マイグレーション後
  • Code Pipeline、Code Deploy
  • CloudWatch

再度西澤氏に交代：

• システム・マイグレーションは6ヶ月で完成
  • IT部門 / AWSプロフェッショナルと共に
• サービスは疎結合だが組織は密結合でなくてはならない
• 10名弱、若いメンバー
  • あまり知識も経験も無かった
  • 一歩踏み出すには力不足
• 最初の3ヶ月
  • AWSプロフェッショナルサービスとの打合せ
  • 経験を積むために社内ワークショップを開催
• AWSを選択するに辺り反対もあった
  • ベンダロックインの懸念
  • -> コアとして護るべき所との切り分けがワークショップで掴めた
• 費用
  • PoCの範囲であればほぼ無償でできた
  • ユニット単位で作っては壊す
  • ビジネスロジックを最適に分割 -> コストを試算

まとめ

• ビジネスは容赦なく変化する
  • 技術：戦い抜けるアーキテクチャを
  • 組織：踏み出す勇気と受け入れる心
• 価値提供に集中できるチームへ
  • フルスタックエンジニア
  • ビジネス - IT / Dev - DevOps
  • 隙間を補完 <-> 自己成長

所感

「サービスは疎結合だが組織は密結合でなくてはならない」という言葉が印象的でした。

プレゼン中に何度も「AWSプロフェッショナルと組めたことが大きい」と述べており、営業トークではなく本当に感謝されているという意思が伝わってきました。

ただ個人的には、プロジェクトがしっかりとした意思と具体性をもって進められた印象をもちました。ロックインの話もプレゼン中にありましたが、AWSありきではなく、ビジネス側とIT側が協力し、要件定義した結果最適解がAWSであったのだろうと感じたセッションでした。